Mi nombre es Juan Luis Ramos Villalón, soy
licenciado en Ciencias Físicas con Especialidad
de Electricidad, Electrónica e Informática.
He acabado de comenzar el tercer curso en
el programa de doctorado de Ingeniería de
Sistemas y Control de la Universidad Nacional
de Educación a Distancia bajo la dirección
del profesor Luis de la Torre Cubillo.
En este vídeo, que continúa o complementa al
vídeo presentado el pasado año, voy a resumir
brevemente el plan de investigación seguido
y los desarrollos que hemos realizado durante
el pasado curso 23/24. El acceso al programa
lo hice como titulado superior en posesión
del antiguo DEA. En el proyecto de tesis, le hemos denominado
tecnología blockchain para la gestión de acceso
a laboratorio en línea. Se busca desarrollar
un entorno que permita, mediante contratos
inteligentes desplegados sobre una blockchain,
gestionar la compartición de reservas y acceso
a laboratorio en línea. Se parte de una pequeña
prueba de concepto elaborada en el pasado curso
dentro del trabajo fin de máster necesario
para acceder al programa, como decía, como
titulado superior en posesión del DEA.
Partimos de un entorno desarrollado o desplegado sobre
una máquina virtual Linux en el Centro Asociado
de la UNED en Melilla, en el cual hay un prototipo
desarrollado en Javascript que se ejecuta sobre Node.
js, que consta de un frontend y un backend.
El backend es un nodo simulado
de la red Ethereum, la blockchain más utilizada,
y un contrato inteligente desplegado con la
herramienta de Baja programación Solidity.
La herramienta para simular el nodo Ethereum es HardHat.
Para hacer las pruebas se ha elaborado
también un pequeño frontend para verificar
cada una de las funcionalidades que se van desarrollando.
La metodología utilizada es una metodología en espiral, en la cual se
analizan los requisitos, se revisan, se hace
una fase de desplegue y desarrollo, y se comproban
los resultados volviendo a iniciar la espiral
añadiendo funcionalidades o complementando
las que ya dispone cada uno de los prototipos desarrollados.
Durante este curso pasado, el 23-24, se completó el primer desarrollo
realizado para el trabajo, y una de las principales
limitaciones que nos encontramos es que el
contrato superaba el límite de los 24 KB,
por lo que fue necesario utilizar librería.
Probamos que el diseño era más cercano a la
programación convencional, que las posibilidades
que ofrecen las cadenas de bloques, no había
ningún código reutilizado, ni ningún tipo de librería.
Se comprueba en la imagen como
uno de los contratos desplegados se acercaba
a ese límite de 24 KB, con lo cual nos hizo
replantearnos el desarrollo que estábamos haciendo.
Hay una pequeña muestra de los contenidos de la investigación en la URL
que se muestra debajo de la imagen.
La siguiente fase fue, por tanto, incorporar
el siguiente prototipo, incorporar estándares
ECREUM al desarrollo utilizando, se eligió
utilizar unas librerías abiertas de la empresa
Open Zeppelin, de forma que los propietarios
y usuarios de los diferentes laboratorios
en línea accedían a ello mediante control
de acceso ya más estandarizado, como son el
mandatory y el role-based access control,
como estándares de control de acceso a los laboratorios.
Asimismo, utilizamos el famoso
estándar RC721, los conocidos NFT, para asignar
la propiedad de los laboratorios a los distintos
propietarios de estos. Y para hacer reservas
de los laboratorios por parte de los usuarios
se utilizó el estándar RC809, que no está
totalmente aprobado, pero que está basado
en las librerías que están en funcionamiento,
que hacen a esos NFT rentables, alquilables
o usables por otro tipo de usuarios diferentes al propietario.
Y para las reservas se utilizaron
técnicas de trimap para la búsqueda de
slots disponibles a la hora de reservar los
diferentes laboratorios. El diseño fue mucho
más modular, ya con librerías externas, no todo el código era propio.
Se redujo el tamaño de los contratos y se alejó del límite máximo.
A su vez, básicamente, aparecen librerías y diferentes contratos
en la implementación. Igualmente eso
puede ser consultable en la URL indicada.
El siguiente prototipo incorporó un nuevo
estándar, el RC2535, que se denomina Diamante
o Diamond Multiphase Proxy. Hicimos primeras
pruebas con un token fungible para utilizar
un token propio, sin necesidad de intercambiar
Ether en las distintas transacciones.
La necesidad de utilizar el RC2535 se convierte
en un contrato inteligente y modular, que
puede ser modificado después de ser desplegado.
Hay que indicar que los contratos en la blockchain
no pueden modificarse, solo pueden crearse o destruirse.
Se hizo una implementación
basada en Diamond Uno Hardhat, indicado ahí de
NithBadgen, y no obtuvo exenta de limitaciones.
Fue un cambio bastante grande en la forma
de hacer el desarrollo. Hubo que reutilizar
otro tipo de librería de OpenZeppelin, la
versión actualizable, Bulky Label, y reconvertir
las librerías propias que habíamos elaborado
en la fase anterior, también para que fueran
actualizables y que pudieran utilizarse como
facet, como cara de ese diamante.
El contrato tiene una serie de ventajas.
El contrato se le asigna una dirección Ethereum.
No hay ya un tamaño máximo, realmente cada 24kb vemos
en la imagen que hay un facet, un contrato
que se acerca, y no hay más que reordenarlo y
distribuirlo en diferentes facets o utilizar
en diferentes librerías. No hay límite,
por tanto, y se bajaría ese límite de los 24kb.
Lo hace mucho más modular y escalable, y
permite añadir, sustituir y eliminar funcionalidades
sin necesidad de destruir el diamante, el
contrato original, de forma que la
dirección Ethereum se mantiene única.
Al utilizar un estándar NFT, como un estándar de token
para el NFT de 121, para utilizar el RC20 como
un intercambio de token entre los usuarios,
es necesario desplegar un contrato externo
al diamante, pero igualmente si se actualiza
el diamante no hay más que incorporar la
información de esa actualización al entorno del diamante.
Con estos resultados se elaboró
en El Segundo trimestre de 2024 un artículo
que actualmente se encuentra bajo revisión,
en el cual se busca aplicar el desarrollo
o los resultados obtenidos de una forma más
genérica, considerando los laboratorios remotos
como sistema ciberfísico. El artículo que
plantea es el uso de una cadena de bloques
sin permiso con la aplicación de sus estándares,
tanto fungibles como no fungibles, proporcionando
una forma de administrar y monetizar el acceso
a los sistemas mientras mantienen sus medidas
de seguridad habituales. El trabajo futuro
es finalizar el prototipo incorporando los
estándares de token fungibles, situación en
la que me encuentro actualmente, realizar
pruebas y despliegue en una testnet, una simulación
pero ya fuera del entorno del servidor en
el centro asociado, fuera del entorno de desarrollo,
para almacenar la información acerca de los
laboratorios, utilizar almacenamiento descentralizado
con un IPFS y realizar ya pruebas con laboratorios en línea.
Estos son los objetivos que tenemos marcados para este tercer curso.
Y nada más de lo que ha sido de su agrado y utilidad. Muchas gracias.
[AUDIO_EN_BLANCO]